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Automatic  Programming 


Introduction 

The  term  "automatic  programming"  was  used  by  some  of  the  early 
designers  of  compilers  to  describe  the  fruits  of  their  efforts.  There 
is  reason  to  believe  that  they  were  overly  sanguine,  but  they  did 
succeed  in  automating  much  of  what  programmers  did  at  that  time. 

The  problem  of  parsing  arithmetic  expressions  was  a  serious  intellectual 
issue  and  its  solution  led  to  important  theoretical  and  practical 
advances.  There  is  currently  a  revival  of  the  term  "Automatic  Programm¬ 
ing"  and  a  certain  amount  of  work  directed  toward  automating  what 
programmers  do  at  this  time.  This  coincides  with  an  increased  amount  of 
work  on  how  people  should  write  programs,  discussed  by  Hansen  in  this  issue. 

Almost  anything  in  computer  science  can  be  made  relevant  to  the 
problem  of  helping  to  automate  programming.  We  will  supress  discussion 
of  work  on  editors,  file  systems,  numerical  methods,  etc.,  and  try  to 
point  out  the  basic  results  and  problems  in  the  field.  Even  so,  a 
paper  of  this  size  cannot  deal  adequately  with  the  many  important 
questions. 

We  begin  by  making  a  rough  division  of  the  work  on  automatic 
'programming  into  two  types .  Type  1  is  concerned  with  automating  the 
production  of  programs  in  a  particular  domain  of  discourse.  A  system 
of  this  type  will  have  considerable  knowledge  of  the  domain  built  in 
and  will  often  be  asked  to  produce  particular  answers  rather  than 
general  routines.  I  claim  that  important  practical  advances  in  this 
area  are  possible  with  our  current  knowledge.  Efforts  of  the  second 
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typo  are  concerned  with  the  fundamental  problems  underlying  the  notion 
of  automatic  program  synthesis.  These  are  general  and  are  normally 
restricted  to  generating  demonstrably  correct  programs.  Systems  con¬ 
structed  along  these  lines  should  not  be  expected  to  be  practical  in  the 
near  future  and  are  thus  relegated  to  Section  2  of  this  paper. 

1.  Direct  approaches 

Even  within  TyPe  1,  there  are  a  variety  of  ways  of  viewing  the 
proglem.  In  its  simplest  form,  automatic  programming  is  just  an  atavistic 
proliferation  of  special  purpose  languages.  To  an  extent  that  does  not 
seem  to  be  understood,  special  purpose  languages  are  not  only  easier  to 
use,  but  can  be  much  more  efficiently  compiled.  [13]  There  has  been 
widespread  use  of  special  purpose  languages  in  some  fields  [33]  but 
subroutine  packages  are  much  more  common.  One  reason  for  this  is  that 
there  has  not  been  enough  additional  benefit  to  warrant  putting  a 
special  purpose  language  around  a  package  of  routines.  If  the  compiler 
puts  together  the  routines  in  an  obvious  way,  the  user  might  just  as 
well  do  it  himself.  One  can  view  Type  1  work  on  automatic  programming 
as  attempting  to  provide  languages  in  which  it  will  be  much  easier  to 
write  good  programs  involving  large  packages  of  routines. 

A  major  problem  one  faces  when  trying  to  automate  the  writing  of 
programs  is  this:  How  is  one  to  say  what  is  required  without  writing 
s  ome  kind  of  program?  Workers  in  Artificial  Intelligence  have  long 
faced  this  problem  of  process  description  and  state  descriptions.  A 
state  description  for  the  function  squareroot(z)  might  be: 

(l)  The  X  such  that  X*X  =  Z 
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A  process  description  for  th«  same  function  might  be  an  AI/30L  program 
to  carry  out  Newton’s  method  for  the  solution.  Two  remarks  are  in  order. 

The  state  description  above  is  much  simpler  than  any  process 
description  —  this  is  not  always  the  case.  It  is  easier  to  describe 
how  to  take  the  derivative  of  a  polynomial  than  to  specify  a  set  of 
properties  that  a  derivative  must  have,  similarly,  the  syntax  of  a 
programming  language  is  given  more  clearly  by  a  grammar  than  by  a  set 
of  conditions  for  well-formedness.  The  ease  of  giving  either  a  state 
or  process  description  clearly  depends  on  the  language  used  for  descrip¬ 
tion. 

Secondly,  in  writing  a  squareroot  procedure  one  is  forced  to 
consider  many  details  which  are  left  out  of  (1).  For  example,  what 
precision  is  required,  are  temporary  cells  available,  etc..  Any 
translator  which  works  from  state  descriptions  will  (like  people) 
require  a  specification  of  the  side  conditions  which  constrain  its 
choice  of  solutions.  Notice  that  this  virtually  requires  an  autosnatic 
programming  system  to  be  interactive.  The  program  will  not  know  what 
values  to  give  to  side  conditions  and  the  user  will  not  know  what 
conditions  need  to  be  specified.  We  will  deemphasize  the  question  of 
side  conditions  for  the  remainder  of  this  paper,  but  it  will  be  an 
important  issue  in  any  particular  design. 

Now  let  us  consider  how  one  might  design  a  translator  for  state¬ 
ments  like  (l).  Many  systems  have  a  general  Newton’s  method  root  finder 
and  it  would  not  be  hard  to  write  a  compiler  which  recognized  that  (l) 
fit  the  conditions  for  applying  this  routine.  One  would  also  require 
a  symbolic  differentiation  routine,  but  they  are  available.  If  the 
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function  to  be  inverted  could  not  be  differentiated,  a  numerical 
solution  could  be  attempted.  The  range  of  this  class  of  compiler  is 
impressive  —  there  is  a  vast  collection  of  algorithms  in  numerical 
analysis  and  mathematical  programming  which  could  be  employed.  The 
problems  of  designing  a  syntax  which  allowed  for  the  recognition  of 
appropriate  solution  methods  do  not  seem  insurmountable.  Rudimentary 
systems  of  this  sort  have  been  completed  by  Fikes  [15]  and  Elcock 
et  al  [8], 

There  is  a  closely  related  line  of  work  which  has  been  done  in 
the  continuous  simulation  languages.  These  often  provide  fixed  routines 
for  solving  various  boundaiy  value,  optimization,  etc.,  problems.  The 
SLANG  [36]  effort  is  a  very  promising  attempt  to  place  these  features 
in  the  setting  of  a  general  purpose  language.  There  have  also  been  a 
number  of  widely  used  high  level  procedural  and  non-procedural  statements 
in  general  purpose  languages.  An  example  of  a  very  sophisticated  language 
primitive  is  the  COBOL  SORT  verb.  A  typical  statement  might  be: 

SORT  FACULTY  ON  ASCENDING  RANK; 

ON  DESCENDING  AGE; 

One  can  also  specify  additional  keys,  and  procedures  and  files  for 
input  and  output.  The  description  of  a  file  is  written  in  the  DATA 
division  of  COBOL  and  a  description  of  the  equipment  available  for 
sorting  is  described  in  the  ENVIRONMENT  division.  The  COBOL  compiler 
selects  a  sorting  method  based  on  all  this  information.  The  business 
oriented  languages  also  have  powerful  constructs  for  file  handling  and 
report  generation  [33].  None  of  these  has  been  designed  with  all  the 
generality  and  consistency  one  could  desire,  but  they  have  proved  very 
useful  to  business  programmers. 
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We  anticipate  that  Type  1  automatic  programming  research  will 
succeed  in  producing  systems  which  make  programming  in  specific  fomains 
much  easier.  There  are  two  lines  of  research  to  be  pursued  — 
prototype  domain  languages  and  tools  for  building  such  languages. 

The  domain  for  automated  programming  that  has  received  the  most 
attention  is  the  management  information  area.  The  goal  has  been  to 
permit  non-programmers  to  specify  fairly  complex  calculations  on  large 
data  bases.  The  low  success/effort  ratio  should  serve  t-j  warn  us  of 
ultimate  difficulty  of  the  task,  but  shouldn't  prevent  work  on  more 
circumscribed  domains.  Management  information  systems  immediately 
encounter  the  problem  of  natural  language  communication  [7  ]  which  can 
be  avoided  in  many  instances.  There  are  many  large  groups  of  computer 
users  (e.g.  organic  chemists,  payroll  programmers)  who  would  be  willing 
to  use  an  artificial  language  if  it  met  their  needs.  There  are  even 
tightly  restricted  domains  like  the  Brookings  model  of  the  economy  or 
the  NCAR  weather  model  which  might  justify  an  automatic  programming 
effort.  The  idea  is  to  combine  some  of  the  techniques  discussed  below 
with  domain-specific  knowledge  to  produce  systems  which  will  help 
people  describe  what  they  want  the  machine  to  do.  Inevitably,  such 
specific  projects  will  feed  back  ideas  to  the  technique-oriented 
research  described  here  and  the  theoretical  efforts  discussed  in  Section  2. 

There  is  a  common  name  for  a  program  which  translates  a  high  level 
d  escription  of  a  process  into  machine  language  —  a  compiler. 

Compilers  are  among  the  best  understood  of  programs  and  this  Tinder- 
standing  is  one  of  the  cornerstones  of  automatic  programming  research. 
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A  modern  compiler  incorporates  a  large  set  of  ideas  for  parsing  and 
understanding  programs  and  for  producing  output  which  efficiently 
carries  out  the  computation  specified  [21].  The  work  on  global  code 
optimization  [1]  has  been  particularly  important  in  providing  ideas  on 
how  to  represent  and  manipulate  computations.  There  is  at  least  one 
automatic  programming  effort  [5]  which  is  primarily  concerned  with 
optimization  of  high-level  procedural  problem  statements. 

The  introduction  of  complex  data  structures  and  their  operators 
in  this  generation  of  standard  languages  (P$,  Algol  68)  and  the  extensible 
language  efforts  are  also  important  steps  towards  higher  level  programm¬ 
ing.  The  other  relevant  topic  from  systems  programming  is  Translator 

* 

Writing  Systems  (TWS)  [11].  The  concentrated  effort  on  TWS  a  few  years 
back  can  be  viewed  as  an  attempt  to  provide  tools  for  building  special 
purpose  languages.  The  problem  may  have  been  that  they  were  not  sufficient 
ly  ambitious  —  the  languages  constructible  did  not  have  enough 
advantages  to  make  their  construction  attractive.  The  addition  of  domain- 
specific  knowledge  and  some  techniques  from  Artificial  Intelligence  to 
the  ideas  developed  in  TWS  research  should  provide  the  basis  for  systems 
support  for  Type  1  automatic  programming  efforts. 

Artificial  Intelligence  laboratories,  especially  those  with  robot 
projects,  have  been  conducting  research  of  great  relevance  to  automatic 
programming.  The  root  problem  is  that  a  robot  (even  if  it  is  only  a 
hand-eye)  will  have  to  plan  and  carry  out  courses  of  action  (strategies). 
The  automatic  strategy  generation  problem  is  the  analog  of  the  automatic 
programming  problem.  These  are  various  doctrines  on  how  to  attack  this 
problem,  the  most  developed  of  which  is  STRIPS  [l6].  The  existing 
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efforts  have  all  been  quite  primitive  giving  rise  to  strategies  that 
do  not  have  loops  and  that  normally  do  not  have  even  conditional  state¬ 
ments  in  them.  The  strategy  and  program-writing  efforts  will  probably 
diverge.  The  strategy  efforts  will  have  to  cope  with  incomplete  informa¬ 
tion,  error  recovery  and  the  other  vagaries  of  the  physical  world  at 
a  much  earlier  stage  than  automatic  programming  ones.  Perhaps  more 
importantly,  there  are  languages  (Planner  [24],  POP-2,  [39],  QA-4  [32], 

SAIL  [14])  at  the  Artificial  Intelligence  laboratories  which  are  continuous¬ 
ly  evolving  to  meet  the  needs  of  the  strategy  problem.  Currently 
considered  important  are  varied  data  structures,  associative  memory, 
pattern  matching,  automatic  back-tracking,  concurrent  processes  and  the 
procedural  representation  of  knowledge.  I  suspect  that  these  same 
concepts  will  prove  to  be  crucial  in  producing  automatic  programming 
systems.  These  artificial  intelligence  languages  are  also  considered  to  be 
alternatives  to  the  more  abstract  theorem-proving  systems  discussed  in 
Section  2  for  a  wide  range  of  tasks.  One  can  view  these  languages  as  a 
special  purpose  languages  for  writing  automatic  programming  systems. 

The  following  example  QA4  [32]  statement  is  illustrative.  It  is  the 
recursive  definition  of  a  function  SORT,  which  sorts  a  linear  list 
(bag): 

(a)  SORT  =  CASES(M  ]  ,  <  )’, 

\  X  •  Bt  MIN  <X,B>  ,  X  *  SORT(B)> 

There  are  two  cases.  Ihe  first  one  (up  to  the  "  $")  specifies  that  if 
the  argument  is  empty  then  the  empty  bag  is  the  value  of  SORT.  The 
general  case  is  written  in  terms  of  the  pattern  matching  facilities  of 
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QA4  .  The  goal  is  to  find  a  decomposition  of  the  bag  into  an  element 
X  and  a  bag  B  such  that  (t )  X  is  not  larger  than  any  element  of 
B  .  Then  the  value  of  the  function  is  the  bag  formed  by  prefixing 
X  to  the  sorted  version  of  B  .  The  use  of  pattern  matching  frees 
the  user  from  deciding  how  to  find  the  smallest  element,  but  normally 
gives  rise  to  an  inefficient  algorithm.  -  QA.4  will  allow  one  to  write 
a  faster  program  by  specifying  more  details.  A  better  (and  much  more 
difficult  to  achieve)  solution  is  to  have  the  system  compile  efficient 
programs  from  statements  like  (a)  .  This  question  of  code  optimiza¬ 
tion  will  arise  yet  again  in  Section  2. 

More  broadly,  much  of  the  artificial  intelligence  work  in  automatic 

problem  solving  is  pertinent  to  the  specific  problem  of  automatic  pro¬ 
gramming.  This  was  understood  by  Simon  [34]  who  made  an  early  study  of 
the  automatic  program  generation  problem.  The  article  by  Feigenbaum  in 
this  issue  provides  a  good  entry  into  the  current  artificial  intelligence 

literature. 

There  are  many  other  ideas  which  will  also  be  useful  to  builders 
of  automatic  programming  systems.  In  addition  to  computer  science 
developments,  the  problem  as  here  defined  can  exploit  any  systematic 
advance  within  a  subject  domain.  One  of  the  best  examples  of  this  kind 
of  achievement  is  the  MATHIAB  [30]  system  for  symbolic  mathematics. 

There  are  a  number  of  issues  which  cut  across  the  somewhat  artificial 
distinction  we  have  made  between  the  systems  of  the  first  type  and  the 
systems  of  the  second  type.  The  most  important  of  these  is  the  issue 
of  process  description  versus  state  description.  A  second  common 
thread  is  the  idea  of  user  interaction.  Neither  of  the  systems  of  the 
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first  type  or  of  the  second  type  seem  possible  today  without  on-line 
interaction.  It  is  simply  impossible  for  the  program-writing  program 
to  know  what  the  user  wants  nor  for  the  user  to  anticipate  all  of  the 
questions  that  the  program-writing  system  may  o.sk  about  his  task  specifica¬ 
tion.  A  third  common  theme  is  the  idea  of  attaching  extra  information 
to  the  statement  of  the  problem  so  that  side  conditions  or  predicates 
that  must  be  satisfied  can  be  added  to  a  program.  This  idea  was 
present  in  the  frequency  statements  to  help  optimization  of  early 
compilers.  More  recently,  Lowry  [27]  has  suggested  using  range  state¬ 
ments  (e.g.  this  variable  takes  only  values  from  1  to  4  )  to  aid  in 
both  error  detection  and  optimization.  Assertions  in  addition  to  or  in 
place  of  procedural  statements  play  a  central  role  in  theoretical 
studies  of  automatic  programming. 

II.  Theoretical  Studies 

Much  of  the  impetetus  for  the  renewed  interest  in  automatic 
programming  came  from  the  demonstrations  by  Waldinger  [38]  and  Green 
[20]  that  theorem  proving  programs  were  capable  of  producing  simple 
programs.  There  has  been  a  great  deal  of  attention  devoted  to  solving 

problems  of  the  general  form: 

(2)  Find  F(x)  such  that  r(x,F(x)) 

where  R  is  some  fixed  relation.  For  example,  we  could  specify  that 
we  wanted  a  square  root  routine  by  saying 

(3)  Find  F(x)  such  that  F(x)*F(x)  =  x  . 

Although  statement  (l)  treated  in  most  general  form  is  equivalent 
to  statement  (3)  the  Type  2  approach  to  the  problem  would  be  quite 
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different.  To  solve  the  Type  2  problem,  a  system  would  have  to  have 
axioms  for  computer  arithmetic  and  be  able  to  constructively  prove  that 
there  was  a  program  which  converged  (presumably  with  an  assumed  accuracy) 
to  the  square  root  for  all  possible  input  values.  This  problem  is  much 
more  complex  than  anything  that  has  been  actually  attempted  with  a  Type  2 
approach.  More  typically  the  programs  attempted  are  in  a  domain  wiih 
simple  axioms,  although  the  logic  of  the  program  produced  may  be  in¬ 
volved.  A  typical  example  is  the  following  one  from  Green  [20], 

The  problem  is  to  construct  a  LISP  program  to  sort  a  list.  The 
theorem  proving  program  must  be  given  the  properties  of  various  LISP 
functions  in  terms  of  axioms.  These  axioms  describe  the  effects  of 
the  functions  when  applied  to  lists.  We  also  provide  a  statement  of 
t  he  desired  result  in  terms  of  a  theorem.  The  theorem  prover  then 
attempts  to  prove  the  theorem  through  a  sequence  of  applications  of  the 
axioms.  If  a  proof  is  found,  the  sequence  of  proof  steps  can  be  mapped 
into  a  sequence  of  function  applications  which  constitutes  the  desired 
program. 

We  will  consider  in  detail  only  the  simpler  problem  of  constructing 
a  program  for  arranging  a  pair  of  atoms  in  increasing  order.  Green 
uses  ten  axioms  for  LISP,  typical  ones  being 
(^)  LI.  x  =  car(cons(x,y) ) 

L2.  y  =  cdr(cons(x,y)) 

L 6.  x  =  nil  zd  cond(x,y,z)  =  z 

L7.  x  ^  nil  z>  cond(x,y,z)  =  y 

One  must  then  state  the  condition  which  the  program  is  to  satisfy.  In 
this  simple  case  we  define  a  predicate  R(x,y)  which  applies  to  two 
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pairs  x,y  and  is  true  iff  y  is  a  sorted  version  of  x  (this  is  an 
instance  of  (2)  above). 

(5)  R(x,y)  =  [ [car(x)  <  cdr(x)  3  y  =  x]  a 

df. 

[car(x)  ^  cdr(x)  3  car(y)  =  cdr(x)  a  cdr(y)  =  car(x)]] 
Finally,  we  must  specify  the  theorem  whose  proof  will  result  in 
the  desired  program.  It  is: 

(6)  (Vx)(Ey)R(x,y) 

Given  the  axioms  in  (4),  the  definition  (5)  and  a  definition  of  <  , 
the  program  was  able  to  prove  the  theorem  (6)  by  supplying  the  answer: 

(7)  y  =  cond(car(x)  <  cdr(x),x,cons(cdr(x),car(x))) 
or  in  more  familiar  notation: 

y  =  if  car(x)  <  cdr(x)  then  x  else  cons(cdr(x),car(x))  . 

After  deriving  this  function  for  sorting  a  pair  of  numbers,  Green  goes 
on  to  show  how  a  program  for  sorting  arbitrary  lists  can  be  constructed. 

For  this  purpose  we  need  a  predicate  R1  (x,y)  testing  if  y 
is  a  sorted  version  of  x  for  arbitrary  lists.  The  important  step 
is  to  add  an  induction  axiom  [29]  which  enables  the  program  to  prove 
correctness  for  arbitrary  length  lists.  In  Greens  system  the  user  was 
required  to  specify  the  particular  induction  axiom,  viz. 

(b)  [R1  ( nil , SORT ( nil ) )  A  (Vx)  [~AT0M(x) 

A  Rl(cdr(x),  SORT(cdr(x)))  3  Rl(x,SORT(x)) ] ] 

3  (Vy)Rl(y,SORT(y))  . 

This  states  that  if  the  desired  function  sort  has  the  property  that  it 
sorts  the  empty  list,  i.e.  Rl(nil,SORT(nil)  and  if  R1  holds  for  the 
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car  (tail)  of  a  list  it  holds  for  the  whole  list,  then  sort  is  the 
function  which  makes  R1  hold  for  arbitrary  lists.  Given  this  axiom 
the  program  was  able  to  come  up  with  a  sort  program  for  lists.  The 
problem  is  much  more  involved  than  we  have  indicated  and  he  had  to  use 
great  care  in  breaking  the  problem  into  pieces  his  program  could 


handle. 

Ihe  current  state  theorem  proving  approach  to  program  synthesis 
is  found  in  Manna  and  Waldinger  [291-  They  concentrate  on  a  very 
difficult  problem  which  is  central  to  automatic  programming  -- 
repetition.  All  interesting  programs  have  iterations  or  recursions, 
usually  of  dynamically  detemined  length.  The  choice  of  which  form  of 


repetition  to  use  and  how  to  use  it  is  (with  the  related  question  of 
data  structures)  among  the  most  important  parts  of  program  synthesis 
(by  humans  or  machines).  Manna  and  Waldinger  point  out  how  certain 
problems  give  rise  naturally  to  certain  repetitive  structures  and  how 
Ihese  structures  are  naturally  represented  by  different  induction  axioms. 


,he  proper  choice  of  induction  axiom  is  crucial  for  a  program  of  this 
type.  Demonstration  programs  are  constructed  using  the  counting  up  and 
counting  down  version  of  Peano's  axioms  for  the  integers  and  for  list 
axioms  like  (b)  above.  Ko  program  has  yet  been  constructed  which  can 
choose  among  a  large  set  of  induction  axioms,  but  there  is  work  in 
progress  on  this  problem. 

The  theorem  proving  approach  is  obviously  closely  related  to  the 
work  on  program  verification  which  is  discussed  by  Manna  (  )  in  this 

issue.  If  we  are  to  have  an  automatic  program  checker,  it  will  have  to 
be  told  what  the  program  is  supposed  to  do.  This  description  must  itself 
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specify  the  desired  result,  so  one  might  hope  to  have  the  program 
generated  automatically.  In  fact,  the  program  verification  problem  is 
easier  than  the  synthesis  problem  and  is  much  further  along.  Floyd 
[19]  has  suggested  using  the  state-of-the-art  in  both  areas  in  an 
interactive  system  to  help  people  construct  demonstrably  correct 
probrams -  A  related  issue  is  the  formal  translation  of  programs  into 
more  efficient  ones.  The  translation  of  recursion  to  iteration  is  the 
primary  concern  [35]. 

The  general  program-writing  problem  as  stated  in  (2)  is  clearly 
recursively  unsolvable.  Even  when  it  is  solvable,  the  program  required 
may  be  arbitrarily  large  [6].  There  is  another  line  of  theoretical 
work  which  provides  partial  solutions  to  these  difficulties,  while 
encountering  several  of  its  own.  This  is  based  on  the  notion  of  learn¬ 
ing  (inferring)  a  program  from  examples  of  its  behavior. 

This  is  theoretically  feasible  because  of  an  apparently  paradoxical 
result  on  the  inference  of  programs.  Although  it  is  undecidable  whether 
a  given  program  produces  some  output,  a  machine  can  find  the  best  prograi 
which  does  so.  The  formal  development  is  beyond  the  scope  of  this  paper 
[10],  but  we  will  outline  the  basic  idea.  Suppose  we  say  that  the 
complexity  of  a  program  on  an  input -output  pair  is  the  product  of  its 
size  and  the  time  it  takes  to  compute  the  value  of  the  output  given  the 
input.  Suppose  we  have  all  the  programs  enumerated  by  size.  Then  the 
machine  proceeds  as  follows.  Let  P1  (the  first  program)  run  for  one 
second  on  the  input,  then  let  F1  ,  Pg  both  run  two  seconds  and  so  on. 
Eventually  some  program  will  halt  with  the  right  answer.  This  establishes 
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an  upper  bound,  K  on  the  complexity  of  the  best  program.  Any  program 
of  size  greater  than  K  can  not  be  the  best  one.  For  the  finite 
number  of  smaller  programs,  the  machine  simply  lets  each  one  run  until 
its  space-time  product  (complexity)  exceeds  K  and  then  choses  the 
best  value  of  complexity.  This  algorithm,  while  proving  the  claim,  is 
so  inefficient  as  to  defy  even  contemplating  its  implementation.  There 
are  attempts  to  develop  reasonable  algorithms  for  inferring  programs 
as  has  been  done  for  grammars  £4 ] .  If  these  work  out,  the  inference 
method  has  several  advantages. 

First,  the  method  will  always  yield  the  best  program  over  a 
finite  domain,  and  the  same  method  can  be  shown  to  have  good  properties 
in  the  limit  for  countable  domains  [10],  If  a  direct  method  for  solving 
(3)  for  F  fails  the  following  strategy  could  be  applied.  Use  the 
inference  method  to  compute  a  program  P  which  works  for  the  specific 
values  known  to  obey  R(x,y).  Given  a  new  value  x'  compute 
R(x;  ,  P(x'))  .  If  it  is  true  then  P  also  works  for  x 7  .  If 
not,  solve  explicitly  for  a  value  y'  such  that  R(x'  ,  y ' )  by 
numerical  or  search  techniques,  infer  a  new  program  P'  which  has 
P'(x')  =  y'  and  continue.  This  entire  procedure  will  work  in  many 
cases  where  theorem  proving  techniques  would  not  and  has  at  least 
theoretical  interest.  Inference  techniques  also  have  the  obvious 
advantage  that  they  can  be  used  when  only  examples  of  the  input-output 
pairs  are  given.  Other  inferential  methods  are  being  considered  by 
Amarel  [ 2 ] . 

The  abstract  work  is  meant  to  uncover  basic  principles  which  underly 
the  problem.  The  people  who  work  in  this  area  fully  realize  that  for 
practical  solutions,  their  ideas  will  have  to  be  combined  with 
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those  of  the  first  type,  incorporating  specific  knowledge  of  the  domain 
begin  treated.  In  fact,  the  system  of  King  [25]  and  the  proposed  system 
of  Floyd  [19]  are  based  on  the  use  of  domain-specific  rules  of  inference 
and  most  Type  2  efforts  are  becoming  concerned  with  efficient  strategies 
for  proofs  in  restricted  domains.  This  brings  them  in  close  contact 
with  the  artificial  intelligence  languages  designed  to  be  used  for 
searching  solution  spaces.  The  pattern  matching,  backup,  etc.  of  these 
languages  is  well  suited  for  writing  directed  proof  procedures.  The 
central  problem  is  the  representation  of  specific  knowledge  in  a  way 
that  will  be  simple  enough  for  programs  to  manipulate,  but  rich  enough 
to  efficiently  direct  the  problem  solving  program. 

There  will  never  be  a  "solution"  to  the  automatic  programming 
problem.  Consider  the  following  simple  statement  over  the  positive 
integers: 

(8)  Find  A,  B,  C,  N  such  that  N  >  2  and  AN  +  bP  =  cF 

There  are,  however,  specific  lines  of  work  which  promise  to  yield 
practical  benefits  or  insights  into  the  nature  of  programs.  One  can 
hope  that  this  spurt  of  interest  in  automatic  programming  will  be  as 
fruitful  as  the  last. 
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